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(57) Abstract 

A computer ncworlc having a number of wortcstations running ^^^^^^^^^^^^^J^^ "aJl'^'^Sl m Gl^TgS 
backup and restore of data on the network. TTie fiUer server nins a gencnc ^y'^^.J^'^^i^^ The GRFS file 

p^gr^s which allow the GRFS file system to access dau withm a ^^^kstatmn havmg a g^^'^^^''^^' $nppo« the 
systWinterfaces with each GRFS agent program via a command'response P^^^'S"^*!* * ' SlnTsystems. and to allow 

disparate operating systems for backup and restore, to allow data to be mterchanged between the disparate operating sysic 
independent multiple users of the network to request simultaneously backup or restore. 
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data area is at most 1,024 bytes. Furthermore, there are 
several fields within the DBLK structure, which are 
actually pointers to infomation within the DBLK data 
area. These pointers are generated as offsets from the 
5 beginning of the DBLK structure. For example, if the 
DBLK common area is 80 bytes long and the first item 
within the data area is the object's name, then the 
object name field would be set to 80 in order to point to 
the first byte following the DBLK common structure. The 

10 individual fields within the common DBLK structure that 
are manipulated by the GRFS agent programs are described 
in detail below under the heading "DBLK Fields". 

In order to implement a backup and restore function 
for a given computer 12, that computer 12 should 

15 advertise its capability for this purpose. Not every 
coir5)uter 12 in the network 10 is necessarily running a 
GRFS agent program so as to be able to have its data 
backed up. Consequently, the GRFS agent programs will 
"advertise" their capability as a GRFS agent over the 

20 network 10. This may be accomplished using the NRL 
resource advertisement function. The GRFS agent resource 
advertisement publishes the logical name of the 
particular agent's root DLE, as well as various flags 
which are used by the GRFS file system to control access 

25 to the GRFS agent. The format of the GRFS agent 
advertisement structure is as follows: 
struct grfs ws adverts true t 

{ 

CHAR major_ver; 
30 CHAR minor_ver; 

CHAR agent_type; 
CHAR flags; 

CHAR name [MAX.W0RKSTATI0N_NAME_LEU1 ; 
} 

GRFS agents use character representations of the 
values in the version and flags fields. For example, the 
major. minor version of a particular GRFS agent might be 
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DATA BACKUP AND RESTORE SYSTEM PGR 
A COMPUTER NETWORK 

BACKGROUND OF THE INVENTION 
5 Field of the Invention 

The present invention relates to a system for 
protecting data through backup and restore operations, 
and more particularly to backup and restore software for 
protecting data which is processed on a computer network 

10 

Description of the Related Art 

In order to ensure that original data stored on a 
medixim such as a disk is not lost or damaged, a copy of 
that data is stored on another medium. Should the 

15 original data be lost or damaged, then the copy may be 
accessed to reproduce the original data. This process of 
copying and reproducing is generally known as backup and 
restore- Typically, original data are stored on a hard 
or floppy disk of a computer disk drive and are backed up 

20 to and restored from tape media of a tape drive* 

Backup and restore of the data are. simple in a 
system that has a single standalone computer, having a 
given operating system and one or more disk drives, that 
interfaces with a tape drive system. A relatively simple 

25 backup and restore program can be used that interfaces 
with the computer operating system to " backup data 
including files and directories stored on a hard disk to 
the tape drive and to restore such data from the tape 
drive onto the hard disk. 

30 Computer networks have evolved and this has placed 

greater demands on backup and restore systems. A 
computer network may include a number of computers each 
with its own hard and/or floppy disk drive, all of which 
are networked together on a common bus. For example, the 

35 coiT^uters on the network may include one or more 
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"0043ONE_WOLF" major version « 0 

minor version = 0 
Unix agent 
user name required 
5 password required 

DLE name = "ONE_WOLP" 

Fig. 4 illustrates a sequence of GRFS command and 
10 response messages in simplified form to backup data on 
the tape drive TD of the file server FS. This Fig. 4 
gives the example of backing up a 5000 byte file named 
C0MMAND.COM which is stored on a "DRIVEC" of a given 
workstation named "DougCompaq" . It is assumed that the 
15 given workstation WS has advertised over the network 10 
sufficient information so that the GRFS file system can 
create the first command message shown in Fig. 4 as 
ATTACH_DLE(. 

To begin the 5000 byte backup, the workstation user 

20 will, via a given user interface 18, cause a display on 
a monitor M of devices and suibdevices. The user will 
then select a given subdevice (e.g., DRIVEC in the 
example of Fig.. 4), resulting in the user interface 
displaying on monitor M names of various files and 

25 directories. The user will then select the file name to 
be backed up (C0MMAND.COM in the example) resulting in 
the submission of a tape backup job for the file server 
FS in the network 10. 

Next, the sequence of GRFS file system command 

30 messages and GRFS agent response messages will occur as 
shown in order in the simplified Fig. 4. The sequence, 
as illustrated, commences with the GRFS command message 
ATTACH_DLE( naming "DougCompaq" (dle.id=01) and completes 
with the final GRFS agent response message 

35 DETACH_DLB_STAT ( ) by which DougCompaq (dle.id=01) is 
detached. Thus, the file C0MMAND.COM will be read from 
DRIVEC and written onto the tape drive TD of the file 
server FS for network 10. 
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obviously increases as more and more disparate operating 
systems are added to the network via the computers on 
which they run. 

In general, prior backup and restore systems for 
5 computer networks are limited to the number of different 
types of operating systems that can be supported. This 
places expansion limitations on the network in terms of 
adding computers running additional types of operating 
systems. Also, these backup and restore systems do not 
10 have the capability of interchanging data between 
different operating systems. Furthermore, bottlenecks 
occur and productivity is limited with prior backup and 

« 

restore operations since multiple users cannot 
simultaneously request these operations. 

15 

SUMMARY OF THK INVENTION 

The present invention provides a backup and restore 
system for use on a computer network having computers 
running disparate* operating systems. Backup and restore 

20 software has modules including a backup engine 
containing, among other components, a generic remote file 
system (GRFS file system) and GRFS agents, being loadable 
on a computer network having a plurality of computers 
including, for example, at least one file server and at 

25 least one workstation. The GRFS file system may run on 
one computer, e.g., the file server of the network, and 
each GRFS agent may run on another computer, e.g., a 
workstation,^ on the network. The GRFS file system 
roinning on the one computer, i.e., the file server in 

30 this example, is allowed to access a file system of the 
other coii5)uter via the GRFS agent on that other computer 
to backup and restore data on that computer. 

The GRFS file system and each GRFS agent interface 
with one another over the computer network by a set of 

35 defined messages. This messaging system is based on a 
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10 



15 



is used by the backup application's tape format module 
and is written to the backup media of tape device TD. A 
well-known Microsoft Tape Format Version 1.0 
Specification describes stream header structures and also 
contains a list of pre-defined stream header id values. 
The size field must be set to the number of bytes 
contained in the succeeding data stream and should only 
be set in the first stream header structure for a 
particular data stream, i.e., if the stream header id 
value is 0, then the size field does not need to be set. 

An example is presented below of what a Macintosh 
GRFS agent would return in the GRFS_READ_OBJ_STAT 
messages when a file with a 2000 byte resource fork and 
a 4000 byte data fork is being backed up. This example 
also assumes that a GRFS data buffer limit is 1000 bytes. 



20 



25 



strm^header . id«STRM_MAC_RESOURCE 



strm_header.size=2000 
strm_header . id=STREAM_INVALID 



strm.header . size«0 

St rm^header . id=STRM_NORMAL_DATA 

strm_header.size=2000 

stnn.header . id=STREAM_INVALID 

strm_header.size-0 



3 5 s t nruheader . id=STREAM_INVALID 
strm_header . size«0 



30 



40 



strm_header . id=STREAM_INVALID 
strm_header . size=0 



(returns 1st 1000 
bytes . of resource 
fork) 



(returns last 1000 
bytes of resource 
fork) 



(returns 1st 1000 
bytes of data fork) 



(returns next 1000 
bytes of data fork) 



(returns next lOOO 
bytes of data fork) 



(returns last 1000 
bytes of data fork) 
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npgrRTPTIQN OF THE PREFERRED EMBODIMENTS 

Fig. 1 illustrates one example of a computer network 
10 which stores, manipulates, and otherwise processes 
data. The network 10 has a number of computers 12 which 
5 can communicate with one another over a network bus 14. 
In the example of Fig. 1, the computers 12 include a file 
server FS and a plurality of workstations WSi, WS2, WS3, 
WS4, . . .WSn. Each of the workstations WSi-WS„ has a display 
monitor M and the workstations WS,-WS„ include hard disk 
10 drives HDDj-HDD,. The file server FS has its own large 
file server disk drive FSDD and a tape drive TD upon 
which to backup to and restore from data on the network 

10. 

Every workstation WSj-WS^ may be running the same 
15 operating system OS, or each workstation WSj through WS^ 
may be running a disparate operating system, or there 
may be disparate groups of workstations with each group 
running the same operating system. For example, 
workstation WS, and workstation WS2 may both be running 
20 the operating system known as DOS, workstation WS3 may be 
running the operating system known as OS/2, workstation 
WS4 may be running the operating system known as UNIX, 
workstation WS„ may be running the operating system known 
as Macintosh, and other workstations, not shown, or which 
25 may be added to the , network 10, may run the operating 
system known as Windows. Furthermore, the computers. 12 
in the network 10 may be utilizing user interfaces such 
as those known as the DOS user interface, Windows 
graphical user interface, and a server-based NLM (NetWare 
30 Loadable Module) interface. 

The computer network 10 may be, for example, running 
the operating system software known as NetWare 3.X or 4.X 
which is produced by Novell, Inc., of Provo, Utah. 
NetWare is designed to manage programs and data among the 
35 several computers 12 of the network 10. Fig. 1 also 
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alignment. The GRFS messages are defined with a "least 
common denominator" alignment that would apply to the 
aiove- noted major operating systems. Thus, for example, 
a given network 10 which may include workstations running 
5 only DOS, OS/2, and Macintosh, may be expanded to include 
a workstations running UNIX and/or Windows. In other 
words, the present invention supports a scalable network 
for backup and restore purposes from a small or 
departmental local area network (LAN) to a large or 
10 enterprise wide area network (WAN) . 

Furthermore, the message structure enables multiple 
users working at multiple computers 12 on the network 10 
to request simultaneously backup and restore of objects. 
This structure enables the GRFS file system to create a 
15 unique request id for every GRFS command message. 
Consequently, the GRFS file system can communicate 
simultaneously with multiple GRFS agents and, therefore, 
multiple users of the network 10 who at the same time 
want to have backup and/or restore operations performed. 
20 The present invention will manage these requests such 
that they are placed in a job queue in the file server 
FS, thereby allowing each user to operate independently 
from any other user on the network 10 and without waiting 
access to the backup and restore system. 
25 While each user can independently manage his/her own 

data on a given workstation, backup and restore of data 
on the entire network 10 can be centrally managed at a 
single location by, for example, a network administrator, 
from a given workstation or file server, or a system 

30 console. 

The remaining portion of this specification 

describes in much more detail the structure of the 
command/ response messages, followed by a detailed 
description of the individual fields of the GRFS common 
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having the corresponding operating system in order to 
access the file system of that given computer. Thus, for 
example, the DOS GRFS agent 20 will run on a DOS 
workstation WS,, the OS/2 GRFS agent will run on the OS/2 
5 workstation WSj, etc. The package 16 also has a backup 
engine 22 running on the file server FS and includes a 
tape controller device driver and tape positioner to 
control the mechanical operation of the tape drive TD, a 
common file system, and at least one device specific file 
10 system. The latter is a GRFS file system which 
interfaces with GRFS agents 20 via messages described in 

more detail below. 

Fig. 3 illustrates the network 10, but modified to 
include the software 16. As shown, the backup engine 22 
15 is installed at the file server FS, while the DOS, OS/2, 
UNIX, and Macintosh GRFS agents are installed on the 
respective workstations WSj-WSj, WSj, WS4, and WS.. In this 
example, the computer network 10 does not have a computer 
12 running a Windows operating system. Should the 
20 network 10 be expanded to include a Windows workstation, 
then the Windows GRFS agent of the software 16 would be 
installed at that workstation. While not specifically 
illustrated, a workstation user also can opt to have 
installed one of the user interfaces 18 for tape backup 
25 and restore purposes, that is the same as that already on 
a workstation for other purposes. 

As indicated above, a GRFS agent is a program which 
runs on a network computer such as the given workstation 
WS, and which allows the GRFS file system running on 
30 another computer, such as the file server FS, to access 
the file system within the given GRFS agent's computer. 
This access is accomplished by use of an interface 
between the GRFS file system and the given GRFS agent 
over the network bus 14. Specifically, the interface is 
35 defined by a set of GRFS messages which are documented in 
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gPT^rTFTC DESCRIPTION OF COMMAND /RE SPONSE MESSAGES 

3^0 Using GRFS Command and Responee Messages 

This following sections provide the information necessary to 
implement each of the GRFS command and response messages. 

3 . 1 GRFS_ATrACH_DLE_, GRFS_ATrACH_DLE_STAT 

After establishing an NRL session with the GRFS agent, the first 
GRFS coirenand the backup application will send to the GRFS agent is 
the GRFS_ATTACH_DLE command. The GRFS_ATTACH_DLK command message 
contains the following parameters: 

die name: This field contains the name of the DLE that the 

backup application desires to attach to. The dle_name 
field is encrypted in conjunction with the encryption 
done on the paesword field. The encryption/decryption, 
method used by GRFS is described in the GRFS 
encryption section of this document. 

bee flags: This field contains a bit-mapped value -which defines 

the configuration options chosen by the backup 
application program. The values defined for use xn 
this field are as follows: 

BEC_BACKDP_FrLES_INnSB 0x01 

If this flag is set, then the GRFS agent should 
attenpt to open files even if they are already 
in use by another process. 

BEC_EXTENDED_DATE_SDPPORT 0x02 

If this flag is set, then the backup application 
knows how to handle the ACCESS DATE and ARCHIVB 
DATE fields in the GRFS DBLK, so if the agent's 
OS platform supports these time-8tan5)B, they 
should be provided in DBLKs. 

BEC_SET_ARCHIVB_FIAG 0x04 

If this flag is set and the agent's OS platform 
supports an object "ARCHIVED" flag, then the 
GRFS agent should set an object's ARCHIVED flag 
after the object is closed during the backup 
operation . 

BEC_RESTORE_SECORITy 0x08 

If this flag is set and the agent's OS platform 
has support for security specific data forks (ie 
ACL support for LANMAN OS/2) , then security 
information should be restored diiring the 
restore operation. 

BECJGET_HIDDEN_FI1-ES 0x10 

This flag controls whether "hidden" objects 
should be returned while pr oces sing 

GRFS FIND FIRST OBJ and GRFS^FIND^NETT^OBJ 
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retcode: This UINT16 field is used by GRFS status 

messages to hold the return code of the 
GRFS command. 

reouest id: This UINT32 field contains a value which 

is generated by the GRFS file system for 
GRFS command messages and must be returned 
unchanged in the corresponding GRFS 
response message. 



In the detailed description of the specific GRFS 
messages below under the heading "Specific Description of 
command/Response Messages", the number of parameters 
15 associated with a given GRFS agent is assumed not to 
include the above GRFS common message header. The 
messages use two major structures to define GRFS objects. 
These two major GRFS object types are a drive list 
element (DLE) objects, which are logical devices, and 
20 file system objects, which are files and directories. 
The GRFS messages use DLE structures to reference drive 
list element objects and DBLK (descriptor block) 
structures to reference file system objects. 

A DLE. is a structure that contains information about 
25 individual data storage devices which can be accessed for 
backup and restore. The DLE structure contains, the 
following types of inf onoation: logical device name, 
access password, file system delimiter, etc. 

A DLE structure also supports a hierarchical 
30 structure. A DLE can be a "parent" DLE and can have 
"children" DLEs associated with it. For example, this is 
the case for a Novell server file system. For a Novell 
server, a DLE structure is created which is associated 
with the server and then DLEs for each volume on the 
35 server are created. The same situation can occur with a 
GRFS agent should that agent advertise or publish on the 
network 10 the workstation name as a DLE and then use 
children DLEs to advertise individual areas which can be 
accessed as logical units. 
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epecial^word: 
inax__ob j _be i 2 e 



dlejparent : 



cmpr_^type : 
user name: 



password: 



This field is not used. 

This field contains the size of the buffer that 
the GRFS file system would like to use when 
transferring object data to/from the GRFS agent. 
This buffer size is the size of the object data 
buffer, not the size of the GRFS message buffer. 
GRFS message buffers are larger than the object 
data buffer size because the GRFS message buffer 
must include the 8-byte common header as well as 
the miscellaneouB parameters (obj_id, 
stream info, etc) used by the GRFS_WRITE_OB J, 
GRFS_VERI FY_OB J , and GRFS_RKAD_OB J_StAT 
messages. 

The GRFS object buffer size is a negotiated 
size, so if the value contained in the 
max obj bsize is larger than the agent would 
like, the agent can return a smaller value in 
the GRFS_ATTACH_DIiB_STAT max^obj^bsize field. 
The GRFS file system will use the value returned 
by the GRFS agent if it is smaller than the 
default file system object data buffer size. 

This field contains the DLE handle for the 
parent of the DLE being attached to if a parent 
DI-E exists. If a parent DLE does not exist, 
then this field is set to 0. 

This field is not currently supported. 

This field contains the user name supplied by 
the bac)ajp application. This field will be 
filled only if the DLE is defined as requiring 
a user name. 



This field contains the password supplied by 
backup application if the DLE is defined as 
requiring a password. Even if the DLB requires 
no password, this field will appear to have a 
value until it is decrypted. Please see the 
section on DLE name/Password decryption for more 
information . 

The proper response message for a GRFS^ATTACH^DLE is the 
GRFS ATTACH_DLE STAT message. The parameters associated with the 
GRFS]j>I*B ATTAOTSTAT message are described below. 



die id: 



max connects 



This field must be set to the DLK id which the 
GRFS agent wishes to use to identify the DLS. 
The DLB id is a 32 -bit value which the baclcup 
application will use in future GRFS commands to 
identify the DLE to be operated upon. 
Typically, the GRFS agent will create DLE xds as 
a pointer to a structure of an index into an 
airray. The DLB id can be any value except 0. 

This field should be set to the maximum number 
of concurrent GRFS sessions which the agent xs 
capable of. 
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data area is at most 1,024 bytes. Furthermore, there are 
several fields within the DBLK structure, which are 
actually pointers to information within the DBLK data 
area. These pointers are generated as offsets from the 
5 beginning of the DBLK structure. For example, if the 
DBLK common area is 80 bytes long and the first item 
within the data area is the object's name, then the 
object name field would be set to 80 in order to point to 
the first byte following the DBLK common structure. The 
10 individual fields within the common DBLK structure that 
are manipulated by the GRFS agent programs are described 
in detail below under the heading "DBLK Fields " . 

In order to implement a backup and restore function 
for a given computer 12, that computer 12 should 
15 advertise its capability for this purpose. Not every 
computer 12 in the network 10 is necessarily running a 
GRFS agent program so as to be able to have its data 
backed up. Consequently, the GRFS agent programs- will 
"advertise" their capability as a GRFS agent over the 
20 network 10. This may be accomplished using the NRL 
resource advertisement function. The GRFS agent resource 
advertisement publishes the logical name of the 
particular agent's root DLE, as well as various flags 
which are used by the GRFS file system to control access 
25 to the GRFS agent. The format of the GRFS agent 
advertisement structure is as follows: 
struct grf s_ws_adver_struct 

CHAR major^ver; 
30 CHAR minor_ver; 

CHAR agent_type; 
CHAR flags; 

CHAR name [MAX_W0RKSTATI0N.NAME_LEN1 ; 
} 

GRFS agents use character representations of the 
values in the version and flags fields. For example, the 
major. minor version of a particular GRFS agent might be 
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10 



15 



20 



25 



30 



35 



40 



1.3, so that agent would advertise the version nxunbers as 
"1" and "3", respectively. 

The GRFS major version number is used to control 
which GRFS agents can be accessed by the GRFS file 
system. The GRFS major version number of the GRFS file 
system and the GRFS agent must match exactly or no 
information of the existence of that GRFS agent will be 
given. The GRFS minor version number may be used for 
informational purposes only. 

The agent_tyi)e field is used to define the type of 
GRFS agent. For example, the following values may be 
defined for this field: 



DOS 
0S2 

MACINTOSH 
UNIX 



1 
2 
3 
4 



The GRFS flags field is a bit -mapped value with the 
following flags currently defined: 



GRFS_WS_PAS S WORD_REQ 
GRFS_WS_USER_REQ 



0x01 
0x02 



Combining all the GRFS resource advertisement fields 
leads to the following . examples of GRFS agent 
advertisements : 



NRL Resource 



12 11RATB0Y_4 86" 



Decoded As 



" 1020SLEDGEHAMMER" 



major version = 1 
minor version = 2 
DOS agent 

no user name required 

password recjuired 

DLE name = "RATB0Y_486" 

major version = 1 
minor version « 0 
OS/2 agent 

no user name required 

no password required 

DLE name - "SLEDGEHAMMER" 
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"00430NE_WOLF" major version = 0 

minor version = 0 
Unix agent 
user name required 
5 password required 

DLE name = "ONE_WOLF" 

Fig. 4 illustrates a sequence of GRFS command and 
10 response messages in simplified form to backup data on 
the tape drive TD of the file server FS. This Fig. 4 
gives the example of backing up a 5000 byte file named 
C0MMAND.COM which is stored on a "DRIVEC" of a given 
workstation named "DougCompaq" , It is assumed that the 
15 given workstation WS has advertised over the network 10 
sufficient information so that the GRFS file system can 
create the first command message shown in Fig. 4- as 
ATTACHABLE ( . 

To begin the 5000 byte backup, the workstation user 

20 will, via a given user interface 18, cause a display on 
a monitor M of devices and subdevices. The user will 
then select a given subdevice (e.g., DRIVEC in the 
example of Fig. . 4) , resulting in the user interface 
displaying on monitor M names of various files and 

25 directories. The user will then select the file name to 
;be backed up (C0MMAND.COM in the example) resulting in 
the submission of a tape backup job for the file server 
FS in the network 10. 

Next, the sequence of GRFS file system command 

30 messages and GRFS agent response messages will occur as 
shown in order in the simplified Fig. 4. The sequence, 
as illustrated, commences with the GRFS command message 
ATTACH_DLB( naming "DougCompaq" (dle.id=01) and completes 
with the final GRFS agent response message 

3 5 DETACH_DLE_STAT { ) . by whi ch DougCompaq { dl e . id= 01) is 
detached. Thus, the file C0MMAND.COM will be read from 
DRIVEC and written onto the tape drive TD of the file 
server FS for network 10. 
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Fig. 5 shows a sequence of GRFS commaiici/response 
messages to restore information backed up on the file 
server FS of the network 10. In this example, it is 
assumed that a 5000 byte file named CONFIG.SYS has been 
5 backed up from a given workstation and is to be restored 
to DRIVEC of the workstation DougCompaq. After the 
workstation user has selected the file CONFIG.SYS using 
the user interface to select the file CONFIG.SYS for 
restore, the sequence of GRFS command/ response messages 

10 will proceed as shown in Fig. 5. The sequence begins 
with the GRFS command message ATTACHABLE ( and completes 
with the GRFS response message DETACH_DLE_STAT ( ) . The 
file CONFIG.SYS will be read from the tape drive TD and 
restored onto DRIVEC. 

15 As mentioned previously, the command/response 

messages are structured such that objects such as files 
and directories may be backed up from a GRFS agent 
irunning one operating system, e.g., OS/2, and restored to 
a GRFS agent running another operating system, e.g., DOS. 

20 This is accomplished by the messages containing a 

structure GRFS_STREAM_INFO . This structure has the 

following definition: 

struct GRFS_STREAM_INFO { 
UNET32 id; 
25 UNET16 fs_attrib; 

UNET16 tf_attrib; 
UNET64 size; 

) 

30 When the backup application is reading an object, 

the GRFS_READ_OB J.STAT response message contains a 
GRFS_STREAM_INFO structure. The GRFS agent program must 
set the id field of the first GRFS_READ_OBJ_STAT response 
message of each individual data stream to the appropriate 

35 value for the agent's particular operating system. 
Succeeding GRFS_READ_OBJ_STAT messages for the stream 
must have the stream header id field set to 0 
(STREAM.INVALID) . The data in the stream info structure 
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10 



15 



is used by the backup application's tape format module 
and is written to the backup media of tape device TD. A 
well-known Microsoft Tape Format Version 1.0 
Specification describes stream header structures and also 
contains a list of pre-defined stream header id values. 
The size field imist be set to the number of bytes 
contained in the succeeding data stream and should only 
be set in the first stream header structure for a 
particular data stream, i.e., if the stream header id 
value is 0, then the size field does not need to be set. 

An example is presented below of what a Macintosh 
GRFS agent would return in the GRFS_READ_OBJ_STAT 
messages when a file with a 2000 byte resource fork and 
a 4000 byte data fork is being backed up. This example 
also assumes that a GRFS data buffer limit is 1000 bytes. 



20 



25 



30 



35 



40 



strm„header . id«STRM_MAC_RESOURCE 



stnn_header.size=2000 
strm.header . id=STREAM„INVALID 



strm_header . size=0 

strm.header . id=STRM_NORMAL„DATA 

strm_header . size=2000 
strm^header . id=STREAM_INVALID 

strm_header.size=0 
strm_header . id=STREAM_lNVALID 

strm_header . size=0 
strm_header . id=STREAM_INVALID 
strm header. size=0 



(returns 1st 1000 
bytes of resource 
fork) 



(returns last 1000 
bytes of resource 
fork) 



(returns 1st 1000 
bytes of data fork) 



(returns next 1000 
bytes of data fork) 



(returns next 1000 
bytes of data fork) 



(returns last 1000 
bytes of data fork) 
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When the backup application is restoring an object, 
the GRFS commands {GRFS_WRITE_OBJ, GRFS„VERIFY„OBJ) will 
also contain a GRFS_STREAMLINFO structure. The GRFS 
agent must examine the stream header id value to 
5 determine whether the data stream type is supported on 
the agent's operating system platform. If the data 
stream type is not supported the GRFS agent should set 
the response message retcode to FS_DONT_WANT_STREAM. 
This will cause the backup application to skip to the 

10 next data stream or the next object if at the last data 
stream for a particular object. For instance, if an 
object was backed up from an OS/2 agent which supports a 
normal data stream, an extended attribute (EA) data 
stream, and an access control list (ACL) data stream, 

15 then if the object is restored to a DOS agent, the DOS 
agent will return FS_DONT_WANT_STREAM when it receives 
GRFS_WRITE_OBJ commands with stream header. id values that 
indicate either EA or ACL data streams are being restored 
since this data is" not supported by DOS. The DOS agent 

20 will accept the normal data stream which it does support. 
Thus, this functionality allows objects to be backed up 
from an agent running on one operating system cLnd 
restored to an agent running on another operating system. 
As also mentioned above, the message structure is 

25 defined as well, such that backup and restore can be 
supported with respect to most operating systems^ 
including the current major operating systems which are 
DOS, OS/2, I^acintosh, Windows, and UNIX. Each operating 
system will have its own data structures aligned 

30 differently from one another. For example, one operating 
system may have a 1-byte alignment where a data byte may 
be placed anywhere, whereas another operating system may 
have a 2 -byte alignment where a data byte may be placed 
in either an even or odd byte location. Other operating 

35 systems, for example, may have what is known as a 4 -byte 
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alignment. The GRFS messages are defined with a "least 
common denominator" alignment that would apply to the 
above-noted major operating systems. Thus, for example, 
a given network 10 which may include workstations running 
5 only DOS, OS/2, and Macintosh, may be expanded to include 
a workstations running UNIX and/or Windows. In other 
words, the present invention supports a scalable network 
for backup and restore purposes from a small or 
departmental local area network (LAN) to a large or 
10 enterprise wide area network (WAN) . 

Furthermore, the message structure enables multiple 
users working at multiple computers 12 on the network 10 
to request simultaneously backup and restore of objects. 
This structure enables the GRFS file system to create a 
15 unique request id for every GRFS command message. 
Consequently, the GRFS file system can communicate 
simultaneously with multiple GRFS agents and, therefore, 
multiple users of the network 10 who at the same time 
want to have backup and/or restore operations performed. 
20 The present invention will manage these requests such 
that they are placed in a job queue in the file server 
FS, thereby allowing each user to operate independently 
from any other user on the network 10 and without waiting 
access to the backup and restore system. 
25 While each user can independently manage his/her own 

data on a given workstation, backup and restore of data 
on the entire network 10 can be centrally managed at a 
single location by, for example, a network administrator, 
from a given workstation or file seiver, or a system 

30 console. 

The remaining portion of this specification 
describes in much more detail the structure of the 
command/response messages, followed by a detailed 
description of the individual fields of the GRFS common 

35 
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DBLK structure which may be mcuiipulated by GRFS agent 
programs . 
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fiPRrTFTC DESCRIPTION OF COMMAND /RESPONSE MESSAGES 

3.0 Using GRFS Concnand and Response Messages 

This following sections provide the information necessary to 
implement each of the GRFS command and response messages . 

3.1 GRFS_ATTACH_DLE_, GRFS_ATTACH_DLE_STAT 

After establishing an NKL session with the GRFS agent, the first 
GRFS command the backup application will send to the GRFS agent is 
the GRFS_ATTACH_DLE command. The GRFS_ATTACH_DLE command message 
contains the following parameters: 

die name: This field contains the name of the DLE that the 

backup application desires to attach to. The dle_name 
field is encrypted in conjunction with the encryption 
done on the password field. The encryption/decryption 
method used by GRFS is described in the GRFS 
encryption section of this document. 

bee flags: This field contains a bit-mapped value which defines 
" the configuration options chosen by the backup 

application program. The values defined for use in 
this field are as follows: 

BEC_BACKOT_FILBS_INUSK 0x01 

If this flag is set, then the GRFS agent should 
attempt to open files even if they are already 
in use by another process. 

BEC_EXTENDED_DATE_SUPPORT 0x02 

If this flag is set, then the backup application 
knows how to handle the ACCESS DATE and ARCHIVK 
DATE fields in the GRFS DBLK, so if the agent's 
OS platform supports these time -stamps, they 
should be provided in DBLKs. 

BBC_SET_ARCHrVB_FI*AG 0x04 

If this flag is set and the agent's OS platform 
si5)portB an object "ARCHIVED" flag, then the 
GRFS agent should set an object's ARCHIVED flag 
after the object is closed during the backi^ 
operation . 

BEC_RESTORE_SBCURITy 0x08 

If this flag is set and the agent's OS platfoxn 
has support for security specific data forks (ie 
ACL support for LANMAN OS/2), then security 
information should be restored during the 
restore operation. 

BEC_GET_HIDDEN_FILES 0x10 

This flag controls whether "hidden" objects 
should be returned while processing 
GRFS_FIND_FIRST_OBJ and GRFS_FIND_NEZT_OBJ 
commands • 
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BBC_GET_SYSTEM_FILBS 



0x20 



This flag controls whether "syBtem" objects 
should be retximed while processing 
GRFS_FIND_FIRST_OBJ and GRFS_FIND_NEXT_OBJ 
coxnnvands . 



BBC^PROC^EMPTy^DIRS 



0x40 



This flag controls whether directories which are 
empty should be returned while processing 

GRFS FIND FIRST OBJ and GRFS FIND NEXT_OBJ 
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special^word: 
max obj^bsize 



This field is not used. 

This field contains the size of the buffer that 
the GRFS file system would like to use when 
transferring object data to/from the GRFS agent. 
This buffer size is the size of the object data 
buffer, not the size of the GRFS message buffer . 
GRFS message buffers are larger than the object 
data buffer size because the GRFS message buffer 
must include the 8-byte common header as well as 
the miscellaneous parameters (ob^^id, 
stream info, etc) used by the GRFS_WRITE_0B J , 
GRFS_VERIFY_OBJ, and GRFS_READ_OBJ_STAT 
messages. 

The GRFS object buffer size is a negotiated 
size, so if the value contained in the 
max obj_bsize is larger than the agent would 
like, the agent can return a smaller value m 
the GRFS_ATTACH DLE_STAT max_obj_bBize field. 
The GRFS file system will use the value rettimed 
by the GRFS agent if it is smaller than the 
default file system object data buffer size. 

This field contains the DLE handle for the 
parent of the DLE being attached to if a parent 
DLB exists. If a parent DLE does not exiSt, 
then this field is set to 0. 

This field is not currently supported. 

This field contains the user name supplied by 
the backup application. This field will be 
filled only if the DLE is defined as requxrxng 
a user name. 

This field contains the password supplied by 
backup application if the DLE is defined as 
requiring a pasavord. Even if the DLB requires 
no password, this field will appear to have a 
value until it is decrypted. Please see the 
section on DLE name/Password decryption for more 
information. 

The proper response message for a GRFS.ATTACH^D^ is the 
GRFS ATTACH^DLE STAT message. The parameters as socxated with the 
GRPS^^DLB^ATTAaTSTAT message are described below. 



die jparent 



cnipr^type : 



user name: 



password: 



die id: 



This field must be set to the 
GRFS agent wishes to use to i 
The DLB id is a 32 -bit value 
application will use in future 
identify the DLE to be 
Typically, the GRFS agent will 
a pointer to a structure of 
array. The DLE id can be any 



DLE id which the 
dentify the DLB. 
which the backup 
GRFS ccxnmands to 
ope rated upon • 
create DLB ids as 
an index into an 
value except 0. 



max connects 



This field should be set to the maximum number 
of concurrent GRFS sessions which the agent is 
capable of. 
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niax^opensjper^connect : 



This field should be set to the maximum 
number of objects which can be opened 
simuXtaneousXy per GRFS session. 



procesB-ddbs: 
inax__obj_JbBize : 



C3npr_type : 
support8_children : 



path_len: 



curren^^ath : 



This field is not currently supported. 

This field should be set to the maximum object 
data buffer size the agent wishes to use. The 
maximum GRFS message size is greater than the 
maximxom object data buffer size because of the 
additional parameters in the GRFS messages which 
convey object data. 

This field is not currently supported. 

This field is a BOOLEAN flag which should 
be set to 0 if the DLE does not support 
children. A non-zero value declares the 
DLE as supporting children DLBs . A DLE 
declared as supporting children DLEs 
CANNOT support file system objects as 
well. Either a DLE supports children 
DXiBs or file system objects.' Never both. 

This field should be set to the length of the 
string (including the ' /O' terminator) returned 
in the current_path field. Current GRFS agent 
ixiplementations will always start in the logical 
root directory of DLEs when they are attached, 
so the current_path field should always be set 
to and the path_len field set to 1. 

This field should be set to the current path of 
the DIE being attached to. As described above, 
at DLE attachment time, the current path will be 
the logical root of the DLE, so the current path 
is empty (**) . 
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3.2 

GRFS_FIND_FIRST_DLE, GRFS_FIND_NKXT_DIjE , GRFS_FIND_DLB_STAT 

The GRFS_FIND_FIRST__DIjE and GRFS_FIND_NKXT_DLK commands are used 
by the backup application program to enumerate children DLBb for 
DLBb which are. declared as supporting children DLEs. The sole 
parameter associated with these two commands is the dle_id 
parameter. The baclcup application will supply the dle_id value 
which was previously returned by a GRFS_ATTACH_DLE_STAT response 
message The GRFS agent should respond with a GRFS2fiND_DLB_STAT 
message to both the GRFS_FIND_FIRST_DLE and GRFS_FIND_NEXT_DLB 
cCTnnand. 

It is the responsibility of the GRFS agent to determine the 
sequence and keep track of the children DLEs as they are being 
enumerated. The parameter in the GRPS_FIND_DI-E_STAT response 
message are described below « 

die name: This field should contain the name of DLE which is 
" being enumerated. The value must be a null -terminated 

string . 

path delim: This field should contain the ASCII code of the 

character used by the agent's file system. 

pasBwd req: This field is a boolean flag and should be set to 0 if 
" no password is required to attach to the DLE. A non- 
zero value in this field indicates that a password is 
required. 

user_req: This field is a boolean flag and should be set to 0 if 

no user name is required to attach to the DLE. A non- 
zero value in this field indicates that a user name is 
required in order to attach to the DX£. 

die writable: ^ ^ 

~ This field is a boolean flag used to indicate whether 

restore operations are permitted on the DLE. Setting 
this value to 0 will prevent the backup application 
from attempting restore operations . 

last accesB_s\;pported: 

"* This field is a boolean flag used to indicate *rtxether 

the DLE '6 file system supports the last access date 
information. This field is used by the Backi^ 
application to determine whether file -grooming is 
supported for this device. 

08_id: 
os_ver: 
f s^type: 

cryp_type: This field is not currently used. 
anprjtYpBi This field is not currently used. 

more flag:' This field is a boolean flag and should be used by 
" GRFS agents to indicate that the DLE being returned is 

the last child DLE available. If the GRFS agent is 
incapable of knowing ahead of time whether this is the 
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last DLE, then this field can alvays be set to a non- 
zero value (TRUE) . This will force the backup 
application to sent GRFS_FIND_NEXT_DLE commands until 
the GRFS agent responds vrith a"FS_NO_MORE return code. 
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3.3 



GRFS DETACH DLE, GRFS DETACH DLE_STAT 



The GRFS DBTACH_DI.E command is used by the backup application when 
it no longer needs to access a DLE. The message has only one 
command specific parameteri the dle_id of the OLE which the backup 
application wishes to detach from. DLBs will always be detached 
in the reverse order to which they were attached. In other words 
the last DLB which was attached to will be the first to be 
detached from. When a DLE is detached, the GRFS agent can free 
any resources associated with the attached DLE. The 
GRFS_DETACH_DLE_STAT message is the response type for the 
GRFS'dETACH DLB"~coasnand. 
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3.4 

GRFS FIND FIRST^OBJ, GRFS_FIND_NEXT_OB J , and GRFS_FIND_OBJ_STAT 

The backup application uses the GRFS_FIND_FIRST_OBJ ccanmand to 
begin scanning for file system objects. GRFS agents must take 
into account the GRFS find object mask flags which were supplied 
in the GRFS_ATTACH_DLB command. These flags specify whether 
HIDDEN and SYSTEM objects should be returned for 
GRFS FIND FIRST_OBJ and GRFS_FIND_NEXT_OBJ commands. The 
parameters associated with find first command are explained below. 

die id: This field contains the id of the DIiB that the backi^ 
~ application wishes to scan. 

find type: This field contains one of these values: 

0x00 -return all object types found 

0x01 -return only directory objects found 

sname: This field contains the search string qualifier. 

Normally this field will contain the string"*.*". The 
string means that all objects that meet the 

£ind_type criteria should be returned. 

3.4.1 GRFS Agent Path Generation 

When a GRFS agent is creating the path string used for its file 
system's "FindFirst" system call, the following components must be 
included to create the correct path string. The path string must 
begin with the base directory of the DLE. The DLBs current path 
is then appended to the path string. Finally the sname parameter 
is appended to the path string. Ttie GRPS agent must also supply 
path delimeters wherever required. An example of a "PindFirst" 
path string created by the OS/2 GRFS agent is presented below: 

DLE base path: "C:\DOCS" 

DI*E current path: "GRFSXDBSIGN" 

sname : •»♦.♦• 

The GRFS agent creates the path string: "C:\DCX;s\GRFS\DESIGH\*,** 

Agents are responsible for keeping track of %?hen path delimeters 
must be inserted. For exanple when OS/2 GRFS agent publishes the 
root directory" of a disk drive, the path string is created as 
follows : 

DIiB base path: "C:\» 

DLB current path: "DOCSXGRFSXDESIGN" 

sname : 

GRFS agent creates the path string: •C:\DOCS\GRFS\DESIGN\*.*" 

The GRFS agent does not insert a path delimeter after the DLE base 
path because the DLB base path already ends with a path delimeter. 

3.4.2 GRFS Find Info Area 

One of the most important fields in the GRFS DBLK data area is the 
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Find Info area. Operating systems usually require some data which 
was returned from a FindFirst operation in order to perform 
subsequent FindNext operations. GRFS is designed so that the Fxnd 
Info will reside in the GRFS DBLK, and the Find Info wall be 
available to the GRFS agent whenever the GRFS_FIND_NBXT_OBJ 
command is issued. This is acconplished by passing the DBLK 
containing the Find Info back and forth between the bacKiq> 
application and the GRFS agent. 



23/1- 



SUBSTITUTE SHEET (RULE 26) 



eNSDOCID <WO 95135S0A1 I > 



wo 95/13580 PCT/US94/12915 



The backup application will never modify the Find Info data area. 

The GRFS FIND^NBXT_^0BJ message has only two parameters: 

die id: This field contains the id of the DLE that the backxip 
"* application wishes to continue scanning. 

dbllc: This field is a DBLK which contains the Find Info data 

required for the agent to perform a FindNext 
operation . 

The GRFS agent must respond with a GRFS_FIND_OBJ_STAT response 
message to both the GRFS_FIND_FIRST_OBJ and the GRFS_FI1ID_NEXT_0BJ 
commands . The psurameters "within this response message are 
described below: 

Box'e flag: This field contains a boolean value that can be used 

by the GRFS agent to indicate to the GRFS file system 
whether there are any more objects available after the 
object currently being returned. If the more_flag.is 
set to 0 (FALSE) , then the next time the baclcup 
application makes a FindNextObject function call, the 
GRFS file system will immediately return FS_NO_MORB 
and will not a transmit GRFS_FIND_NEXT_OBJ command to 
the GRFS agent. If the agent is unable to know in 
advance if the object being returned is the last 
object available, then the agent can always set this 
field to a non-zero (TRUE) value. This will force the 
GRFS file system to send a GRFS_FIND_NEXT_OBJ command 
and the GRFS agent to respond with a FS_N0_M0RB return 
value . 

dblk: This field must be a complete GRFS DBLK.^ If a 

directory object is being returned^ then the directOJTT 
name should be a full path relative to the DUSs base 
path. For exasple, if the current path of a DLB is 
••0S2/sySTBM", and the agent is returning the directory 
"TRACE", then the path returned in the DBLK data area 
wotild be "0S2\SYSTKM\TRACB" . The path must l>e null* 
terminated, and the null -terminator character must be 
included in the path length field in the DBLK common 
structure. Root directory objects are returned with 
the path name '\0' and the path-leng field set to 1. 

File object names are also returned as null -terminated 
strings, but only the actual file name is returned. 
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3,5 GRFS_FIND_CU)SE and GRFS_FIKD_CLOSE_STAT 

The GRFS FIND_CLOSB command is used by the backup application when 
it is done scanning a particular directory. When a CRTS agent 
receives a GRFS_FlND_CLOSE message, the agent is allowed to 
release any resources associated with the 
FindFirst/FindNextf unctions. The are two parameters in the 
GRFS FIND CLOSE message and they are described below: 

dle^id: 
dblk: 

The proper response message type for the GRFS_FIND_CU)SB command 
is the GRFS_FIWD_CIiOSB_STAT message. There are no parameters 
associated with the GRFS FIND_CLOSB message. 
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2,s GRFS_GET_OBJ_INFO, GRFS_GET_OBJ_INFO_STAT 

The GRFS GET OBJ_INFO coimnand ie used by the backup application to 
retrieve a completed DBLK when the backup application has only a 
partially complete DBLK. The only DBLK fields which are required 
to contain valid data when the DBLK is passed to the GRFS agent 
are the blk type (dir or FILE) and the object name in the DBLK 
data area? The proper response message type is 

GRFS GET_OBJ_INFO_STAT, The only parameter in the response 
message is the fully con?)leted DBUC. 

There is one slight difference between how a DBLK is created for 
the GRFS GBT_OBJ_INFO command. All other GRFS commands which 
create DBLKs return a fully specified path as the object name for 
directory objects. The GRFS_GET_OBJ_INFO_STAT DBLK returns OKLY 
the directory name as the path data in the DBLK data area. This 
is a "truth". 

**** If the DBLK sent to the agent contains a Find Info area, 
then the agent MUST preserve this data within the DBLK i^ch 
is returned to the backup application. 
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3.7 



GRFS GET CURRENT DDB, GRFS_GET_CURRBNT_DDB_STAT 



The GRFS GET_CORRENT_DDB command is used by the backup application 
to retrieve a DBLK corresponding to the DLBs current directory 
path. The proper response message type is GRFS_GKT_OBJ_INFO_STAT. 
The directory path string returned in the DBLK must be a fully 
specified relative to the DLK's base path. An exas^le is 
presented below: 

CLE's base path: "C:\0S2" 

DLB's current path: "WINOSaXSYSTEM" 

The path string returned in the DBLK data area would be 
»'WIN0S2\SYSTEM" . An exanple of the DLE's current path being the 
logical root directory is presented below: 

DLB's base path: "C:\0S2" 

DLE'B current path: ** 

The path string data returned in the DBLK data area would be a 
'\0' and the b.d.osjpath^leng field would be set to 1. 

**♦* Whenever a GRFS agent returns a logical root directory 
object DBLJC, the DBLK data area path string should be set to 
'\0' and the b.d,os^ath_leng field should be 1. 
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3^8 GRFS_CREATE_OBJ, GRFS_CRKATE_OBJ_STAT 

The GRFS CREATE OBJ command is used by the backup application 
during restore operations in order to create a file system object. 
The parameters associated with this command are the following: 

die id: This parameter contains the DLE handle of the DLB 
" where the object should be created. 

dblk: This parameter is a con5)lete DBLK and contains the 

type and the name of the object to be created. 

Directory object DBLKs will contain fully specified paths, so the 
CLE's current path is NOT included when creating the full path of 
the object to be created, GRFS Agents must be capable of creating 
all levels of a fully specified directory path from a single 
GRFS CREATE OBJ coamand. For exan^^le, the backup application may 
send'the coiSiand to create the directory «WIN31\W0RD\D0CS\ISPECS- . 
If the any of the directories "DOCS", "WORD", or "WIN31" do not 
already exist, then the agent must first create the preceding 
directories within the fully specified path. 

Pile objects are always created in the DLB ' s ' current path 
directory. 

The proper response message type is GRFS_CREATE_OB J_STAT . There 
are no parameters associated with this response message. 



- 28 - 

SUBSTITUTE SHEET (RULE 26) 



wo 95/13S80 PCT/US94/12915 



3^9 GRFS_OPBN_OBJ, GRFS_OPEN_OBJ_STAT 

The backup application must "open" a file syetem object before any 
read, write or verify operations can be performed on the object. 
The three parameters associated with the GRFS_OPEN_OBJ command are 
described below: 

dle_id: This field contains the DUS handle of the DLE where 

the object to be opened resides. 

mode: This field contains a flag value which is GRFS agent 

must use to determine the mode which should be used to 
open the object. This value will be one of the 
following: 

0 READ mode (backup operation) 

1 WRITE mode (restore operation) 

2 VERIFY mode (conpare operation) 

dblk: This parameter is a complete DBLK and contains the 

type and the name of the object to be opened. 

When a backup application is backing up a GRFS agent, the backi^ 
application may desire to backup files which are already in use on 
the GRFS agent's machine. The BEC_aACKaP_FILES_INUSB flag in the 
bec_f lags field of the GRFS ATTACH^DLE command determines whether 
the GRFS agent should attexfpt to open objects which have already . 
been opened by a different process. If the DLB is configured to 
backup files in use and the agent is able to open the object, then 
the GRFS response message return code should be set to 
FS_OPENED_INUSE . 

When an object is opened successfully, two parameters are returned 
in the GRFS_OPKN_OBJ_STAT response message. The first parameter 
is the obj_id. This parameter is a 32-bit value generated by the 
GRFS agent as an object handle. All succeeding GRFS commands 
which access the object will reference the obj_id. As with DI£ 
handle ids, GRFS agents can use whatever method desired to 
generate the object handle ids. 

A coa5)leted DBLK is also returned to the backup application in the 
response message. If the GRFS agent's operating system platform 
has any OS specific object attributes which are accessible only 
after the object has been succesBfully opened, they can be saved 
in the OS specific area within the DBLK' s data area. One exaniple 
of this is OS/2 "longnames** axe accessible only after the object 
is opened. 
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3.10 



GRFS_READ_OBJ, GRFS_READ_OBJ_STAT 



The backup application uses the GRFS_RKAD_OBJ cotnmand to read data 
from previously opened file system objects. The parameters 
associated with this command are described below: 



obj_id: 



size: 



offset: 



This field contains the object handle id which was 
returned by the agent in the GRFS_OPEN_OBJ_STAT 
response message. 

This field contains the size (inSpl230Xbytes) buffer 
which is available to receive data. The GRFS agent 
should endeavor to return as much data as possible for 
each GRFS_RKAD_OBJ coaanand. 

This field contains the number of bytes offset into 
the object the agent should begin returning data from. 



The proper response message type is GRFS_READ_OB J_STAT . The 
response message has four fields which are described below: 

This field should contain the actual number of bytes 
of data being returned in the response message. 



size: 



blk size: 



Btrm info: 



This field should usually be set to 1. This field is 
used by GRFS agents to request a specific number of 
bytes to be read by the next GRFS_READ_OBJ command. 
This functionality can be used if certain data areas 
must be read as "atomic" objects. 

As an exazi^le, suppose the backup application requests 
to read 20 bytes. The GRFS agent has 14 bytes 
available, and then the next 12 bytes must be read a 
unit. The GRFS would return the 14 bytes, set the 
size field to 14, and set the blk^size field to 12. 
This will force the backup application to request 12 
bytes in the next GRFS_RBAD_OBJ command. 

The GRFS agent must never set the blk^size field 
larger than the negotiated GRFS maximum object bixffer 
size. 

This field is a STRKAM^INFO structure and is discussed 
in section 1.3 of this document. 

This field is the buffer which contains the actual 
data. The size of this buffer is limited to the 
maximum object buffer size as negotiated during the 
OliB attach operation. 
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3,11 GRFS_WRITE_OBJ, GRFS_WRITE_OBJ_STAT 

The backup application usee the GRFS_.WRITB_^OBJ coinmand to restore 
data to a GRFS agent. The parameters associated wxth this conanana 
are described below: 

ob-i id- This field contains the object handle id which was 

oDD^ia. j-etumed by the agent in the. GRFS_OPEN_OBJ_.STAT 

response message. 

size: This field contains the size (in bytes) of the data 

buffer which is to be written. 

offset- This field contains the offset in bytes, from the 

beginning of the object, that the GRFS agent should 
begin writing the data buffer. 

strm info: This field contains a STRKAM^INFO structure. As 
" described for the GRFS RKAD_OBJ response message, the 

first block of each" data stream will have the 
strm info. id field set to the stream data type. All 
succeeding blocks of that data stream type will have 
the strm info. id field set to STKM_INV;a.ID . The fxrst 
block of^a particular stream data type will have the 
strm_info.size field set to the total size (in bytes) 
of the stream. 

GRFS agents should ignore a data block for a stream 
type that they do not recognize, and their response 
message should indicate that the entire block was 
successfully written. 

data: This field is the buffer which contains the data block 

that is to be written. 

The proper response message type is GRFS^WRITE^OBJ STAT This 
response message has the following parameters associated with it. 

size: This field should be set to the number of bytes 

successfully written. 

blk size- This field should normally be set to 1. This field is 
blk.size. THIS .^^^^te that the GRFS agent requires a 

specific number of bytes to be written in the next 
GRFS WRITE OBJ command. Any value other than 1 wiii 
forci the backup application to attenpt to write the 
requested number of bytes during ^^^he next 
GRFS WRITE OBJ operation. The agent should NEVER set 
this" field" to greater than the negotiated maximum 
object buffer size. 
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3.12 GRFS_VERIFY_OBJ, GRFS_VERIFY_OBJ_STAT 

The backup application uses the GRFS_VKRIFY_OBJ command to verify 
that data contained on the backup media matches the data residing 
on the GRFS agent. The parameters associated with this command 
are described below: 

obj_id: This field contains the object handle id which was 

returned by the agent in the GRFS_OPEN_OBJ_STAT 
response message. 

size: This field contains the size (in bytes) of the data 

buffer which is to be compared. 

offset: This field contains the offset in bytes, from the 

beginning of the object, that the GRFS agent should 
begin con^aring the data buffer. 

Btrm_info: This field contains a STRKAM__INFO structure cuid is 

described in section 1.3 of this docxmient. 

data: This field is the buffer which contains the data block 

that is to be verified. 

The proper response message type is GRFS_VKRIFy_OBJ_STAT. This 
response message has the following paramet:er6 associated with it: 

size: This field should be set to the number of bytes 

successfully verified. 

blk^size: This field should normally be set to 1. This field is 
~" used to indicate that the GRFS agent requires a 

Bpecific number of byties to be verified in the next 
GRFS_VBRIFY_OBJ command. Any value other than 1 will 
force the backup application t:o attempt to verify the 
requested number of bytes during the next GRFS^VBRZFY- 
OBJ operation. The agent should NEVER set this field 
to greater than the negotiated maximum object buffer 
size. 
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3^13 GRPS_SBEK_OBJ, GRFS_SEEK_OBJ_STAT 

The backup application uses the GRFS_SEBK_OBJ command to force the 
GRFS agent to move the previously opened object's file locatxon 
pointer to a specific offset within the object. This command is 
typically used by the backup application to seek past sectors 
which are unreadable in hopes that some of the data may be 
readable (HaHa) . The parameters associated with this command are 
described below: 

ob-i id- IliiB field contains the object handle id < which was 
• " returned by the agent in the GRFS_OPEN_OBJ_STAT 

response message. 

offset- This field contains the offset in bytes, from the 

beginning of the object, that the GRFS agent should 
move the file pointer to. 

The proper response message type is GRFS_SEEK_OBJ_STAT. ^ This 
response message contains only one parameter associated with xt* 
The parameter, 8eek_obj_of f set specifies the offset withm the 
object that the agent was able to seek to. 
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3 14 GRFS_CIOSE_0BJ, GRFS__CI/)SE_OBJ_STAT 

The backup application uses the GRFS_CLOSB_OBJ command to force 
the GRFS agent to close a previously opened file system object. 
When an object is closed, the agent is allowed to free any 
resources associated with the open object. The only parameter in 
this command message is the obj^id field. This field contains the 
object handle id which was returned by this agent xn the 
GRFS_0PBN_OBJ_STAT response message. 

The proper response message type is GRFS_CLOSE_OBJ_STAT. There 
are no parameters with this response message. 
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3.15 GRFS_DKLETE_OBJ, GRFS_DELETE_OBJ_STAT 

The GRFS DBLBTB OBJ command is used by the backup application 
during transfer" operations in order to remove a fi^^^ f^^"^ 
object. The parameters associated with this command are the 

following: 

die id: This parameter contains the DLE handle of the DLB 

* where the object should be removed. 

dblk- This parameter is a complete DBLK, and contains the 

type and the name of the object to be deleted. 

♦T^cJn^;Yf^lllv Directorv object DBLKs will contain specified paths, 
*p905Xfully current path is NOT included when 

creating the full path of the object to be deleted. 
The backup application will first remove file ob3ects 
from a directory object before removing the directory 
object. 

Pile objects are always deleted from the DLB's current 
path directory. 

The proper response message type is 
GRFS_DELETE_OBJ STAT. There are no parameters 
associated with'"thiB response message. 
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3.16 GRFS_CHANGE_DIR, GRFS_CHANGB_DIR_STAT 

The GRFS CHANGE_DIR command is used by the backup application to 
force a GRFS agent to change the « current directory" of a specific 
DLB The new path supplied in the message is always a fully 
specified path relative to the DLB's base path. The GRFS agent 
iroST verify that the new path is a valid path. This can usually 
be accomplished by performing a "FindFirst" operation on the new 
path As an added bonus, the backup application may send a "null- 
impreguated" string in the path field. This means that the GRFS 
agent must replace the internal '\0' path delimeters with the 
agent's OS specific path delimeter character. No applause 
necessary. 

The proper response message type is GRFS.C3»NGB.DIR.STAT. There 
are no parameters associated with this response message. 
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3.18 GRFS_SET_OBJ_INFO, GRFS_SET_OBJ_INFO_STAT 

The GRFS SET OBJ_INF0 command is used by the bac)cup application to 
set the ""file system attributes of a file system object. The 
parameters associated with this command are described below: 

die id: This parameter contains the DLE hauidle id of the DLE 

where the object resides. 

dblk- This parameter is complete DBLK and contains the 

object type, the object name, and the object attribute 
data which are to be set. 

The GRFS agent must set the following file system object 
attributes : 

ctime (CREATION TIME) 

atime (ACCESS TIME) (if possible) 

time (MODIFIED TIME) 

size (object data size) 

gen_attr (file system attribute flags) 

The proper response message type is GRFS_SET_OBJ_INFO_STAT. There 
are no parameters associated with this response message. 
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3.19 GRFS_VERIFy_OBJ_INFO, GRFS_VERir3r_OBJ_INFO_STAT 

The GRFS VERIFY OBJ INFO command is used by the backup application 
to verify that "file system object attributes on the GRFS agent 
match the object attributes contained on the backup media. The 
parameters associated with this command are described below: 

die id: This parameter contains the DLE handle o£ the DIjE 

where this object resides. 

dblk: This parameter is a complete DBLK and contains the 

object type, the object name, and the object attribute 
data which are to be con^ared. 

The GRFS agent must verify that the following input parameter DBLK 
fields match the actual attributes of the file system object: 

cdate (CREAT20H DATS) 

mdate (MODIFIED DATE) 

Bize (object data size) 

gen_attr (file system attribute flags) 

The proper response message type is GRFS_VERIFY_OBJ_INFO_STAT, 
There are no parameters associated with this response message. 
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3.20 GRFS_PRKPARB_DBLK, GRFS_PREPARB_DBliK_STAT 

The GRFS_PREPARE_DBIiK command is used so that during restore 
operations the GRFS Agent is able to modify ("image") path and 
directory names into a form which is usable by the target 
(restore) agent's file systems. For instamce, if a bac)cup set is 
created by a Macintosh agent, then the file and directory names 
must be modified in order to restore the baclcup set onto a DOS 
agent's FAT file system 8.3 format. 

die id: This parameter contains the DLE handle of the DLE 
" where the object resides. 

dblk: This parameter is a conplete DBLK and contains the 

object type, the object name. 

The agent should append the modified name at the end of the DBLK 
and alter the "os_* name pointers to point to the new name. The 
agent must also modify the dbl)c.dbl)e_actual_6ize to account for 
the increased DBLK size. If the input name does not require 
modification, then the DBLK can be returned \inmodified. 
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Appendix A - GRFS Technical Reference 

This section of the GRFS Technical Reference appendix shows 
the actual definitions of the structures which have been 
described in this document. All of the structures can be 
found the GRFS-H include file. 



typedef union 
{ 

INT8 

INT32 

} INKT32; 

typedef union 
{ 

tUNTB 
UIOT32 
} VSBT22; 

typedef union 
{ 

IOT8 

IOT16 

} INBT16; 

typedef union 
{ 

0INT8 
niNT16 
} UKET16; 

* 

typedef struct 

{ 

UNET32 
UIiET32 
} UNET64; 



val [41 ; 
nuxn; 



val [4] ; 
nioxn; 



val [2] ; 
nuxn; 



val [21 ; 
num; 



Isw; 
xnsw; 



typedef X7NET 32 DLB HAKDZiB; 
typedef tmET32 OBJ HANDLE; 
typedef UNKT32 REQlHANDLB; 

GENERIC DBUC NETWORK STRDCTDRB 

Struct grf s^gen^dblk^s tr 



{ 

UINT0 
UINT8 
UINT8 



blk_type; 
reel; 

f g^com^reservelSSl ; 



struct STD_OBJ_INPO 
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{ 

UINT8 
UINT8 
UIOT8 
DATEjriME 

date"'time 
datb^time 

DATBjriME 

UNKT64 

UNKT32 

) 8tdl_info; 



os""ver; 
xes2 12] ; 
ctime ; 
atime; 
btime; 
time; 
size; 
gen^attr; 



BOOLEAN 

UNET16 

UNET16 

UNET16 

UNET16 

UNET16 

UNBT16 

nNETl6 

UNET16 

BOOIiBAN 

BOOLEAN 

UINT8 

\2nion 

{ 



OB^inf o^compiete ; 

min_ddb_info; 

min^ddb^size; 

os_spec^inf o ; 

oB^Bpec^eize; 

dbl)c_actual_Bize ; 

tape_attribs; 

name^ccmplete ; 

f ind_in£o; 
f ind_in£o_8ize ; 
t rans 1 at e_f lag ; 
special_f lagr- 
obj^type; 



struct OS_DDB_INFO 



( 

UNET16 
UNET16 
nZ^ET16 
UNET16 

} 

struct OS_FDB_INFO 



o8_path_leng ; 
path_leng; 
path; 



{ 

BOOLEAN 

UNET16 

UNET16 



inuBe_attrib; 
o Byname; 
name; 



typedef st ruc t 
*GRPS JBEN_DBLK_PTR ; 



grf s_gen_dbl)c_Btr grps^GEN.DBLK, 



struct grfs^meBsage 



{ 

UINT8 
UINT8 
UINTIC 



msg^type ; 
reserved; 
retcode ; 
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UNET32 
union { 



request^id 



}; 



/♦* GRFS corotnand parameter 
DLE KAKDLE 

obj'handlb 

grfs attach^dle^parms 
grfsIfind_first_obj_parms 

grfs_object_parms 

GRFS_OPEN OBJ_PARMS 

grfs_read3obj_parks 
grfs_write_obj_parms 
grfs_verify_obj_parms 
grfs_seek_obj_parms 
grfs_change dir_parms 
grfs_enum_spec_parms 

/♦* GRFS responee parameter 

UNET32 

GRFS GEN_DBLK 
GRFS""ATrACH_DLE_STAT_PARMS 

grfsIfind DLB_STAT_PARMS 

GRFS FIND^OBJ^STAT^PARMS 
GRFS^OPEN^OBJ STAT_PARMS 
GRFS READ OBj"STAT_PARMS 
GRFS WRIlf _0BJ_STAT_PAR11S 
GRFS^VERIFY^OBJ^STAT^PARMS 

grfsIenum_spec_stat_parms 

} msg_parms; 



structures **/ 
dle_id; 
obj_id; 
attach_panns ; 
f f _6b j jparms ; 
obj^patrmB; 
open_ob j__parms ; 
read_obj_parmB ; 
write_obj_parnis ; 
ver if y_ob j jpanns ; 
seek_ob j _parme ; 
change^dir_parms ; 
enuin^Bpec _pannB ; 



Btructxires 

seek obj offset; 

dblk? " 
attach_Btat ; 
f ind_dle_8tat; 
f ind_obj_8tat; 
open_ob j^fitat ; 
read_ob j_etat ; 
write_ob j_8tat : 
ve r i f y_ob tat ; 
enum^special^Btat ; 
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This section shows the GRFS coOTnand mesBage types and their 
Srrespon"^^^^^^ GRFS response message types The parameters 
associated with each message are also provided. 



CTPg COMMAND MESSAGES 



GRFS RESPONSE MESSAGES 



GRFS_ATrACH_DI*E ( 



dle_name [] , GRFS^ 
bee_f lags, 
spe ci al__^word , 
max_ob j _bs i z e , 
dlejparent, 
cmp retype, 
user_name [] , 
password!] ) 



ATTACH_DLE_STAT ( dle_id, 
max^conne c t s , 
max_open8_per__connect , 

process_ddbB , 
max_ob j _bB i ze , 
cmpr_type , 
Bupports^children 

path^len, 
current jpath I] ) 



GRFS_FIND_FIRST_DliE ( 



die id) GRFS FIND_pLE_STAT ( dle_naxnell, 
" " path_delim, 

passwd^req, 
user_req, 
dle__writeable , 
support s^last^access , 

os_id, 
oB_ver, 
{s_type, 
crypt_type, 
cmpr^type , 
more_f lag) 



GRFS_FIND_NEXT_DLE ( dle_id) 



GRFS_FIND_DLE_STAT ( dle^name [1 , 

path_delim, 
pasBwd_req, 
user^req, 
dle_writeable , 

os_id, 

os^ver, 

fs_type, 

crypt^type, 

cmpr^type, 

more^f lag) 



GRFS^DETACH ( dle.id) GRFS^DETACH.DLE.STAT ( - - - ) 



GRFS FIND FIRST OB J ( dle^id, GRFS_FIND_OBJ_STAT < 

" ^ " find_type, 

sname [] ) 

GRFS FIND NEXT OBJ( die, id, GRFS_.FIND_OB J_STAT ( 
" " " dblk) 



more^f lag, 
dblK) 



inore_flag# 
dblk) 



GRFS FIND CLOSE ( dle_id, 
" ~ dblk) 

GRFS CREATE OBJ( dle_id, 

dblk) 

GRFS_OPEN_OB J ( dle_id , 

mode, 



GRFS_FIND_aiOSE_STAT ( - - - ) 



GRFS_CREATE_OB J_STAT ( 
GRFS_OPEN_OB J_STAT ( 



— -) 



obj id« 
dblk) 
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GRFS_RKAD_OB J ( 



dblk) 

obj_id, 

size, 

offset) 



GRFS_RKAD_OB J_STAT ( 



GRFS WRrrE_OBJ{ Obj_id, 

size, 

offset, 
strm_inf o, 

buffer [] ) 

GRFS SBEK_OBJ( obj_id, 
" offset) 

GRFS VERIFY OB J ( obj_id, 
" " size, 

offset, 
strm^info, 
buffer I) ) 



GRFS_WRITE_OBJ_STAT { 



size , 
bl)c_Bize, 
strm_inf o, 
buffer [1 ) 

size , 
bl)c_size) 



GRFS_SEEK_OBJ_STAT( seek:_obj_of f set) 

GRFS VERIFY OBJ STAT( size, 

- bl)c_Bize) 



GRFS.CLOSE.OBJ ( obj.id) GRFS.CLOSE^OBJ.STAT ( 



---) 



GRFS DELETE OBJ( dle^id, GRFS_DELETE^OB J.STAT ( --) . 

dbllt) 

GRFS GET OBJ INFO(dle.id, GRFS^GET_OB J^INFO^STAT ( dbllc) 

- ' " dblk) 

GRFS VERIFY OBJ INFO( dle^id, GRFS.VERIFY_OBJ_INFO.STAT ( — ) 

- dblk) 

GRFS CHANGE DIR< dle.id, GRFS.CHANGE.DI R.STAT ( -•) 
" " net^path tl , 

. size) 

GRFS_GET.CUR_DDB ( dle.idj GRFS.GET.COR.DDB.STAT ( dblk) 

GRFS SET OBJ INFO{dle_id, 
• " " dblk) 



GRFS_BNUM_SPBCIAL_FIRST 



GRFS_SET_OB J_INFO_STAT ( ) 

GRFS BNOM SPECIAL STAT ( nam© [] , 

" more^flag) 



GRFS BNUM SPBCIAL.STAT ( name I] , 

~ " more.flag) 



( dle.id, 
enum.type) 

GRFS EKDM SPECIAL^KEXT 

(dle_id, 
enum.type) 

GRFS SPECIAL.EXCLUDE GRFS.SPBCIAL.EXCLUDB.STAT ( - - ) 

" (path_len, 

f name.len, 
data[] ) 

GRFS PREPARE DBLK GRFS.PREPARE.DBLK.STAT ( dblk) 

(dle_id, 
dblk) 
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COMMON GRFS MESSAGE PROCESSING 

All GRFS messages generated by the backup application include the 
following conmon fields : msg_type, retcode, and request ad. The 
msq type field must contain a valid GRFS command value. The 
SickuJ^application will set the reguesc id field CO ^^^^^^ 
the backup application will use to correlate outgoing GRFS command 
meBsages to the corresponding incoming GRFS responBe messages. 
?^e gIfs agent must set the request.id value of the GRFS response 
messaae to the request id value received m the corresponding GRFS 
cl^l messfge.^ The GRFS response message to the requested 
value received in the corresponding GRFS command message. The 
ret code field is not used for GRFS command messages; xt xs 
meaningful only for GRFS response messages. 

Several of the message parameter structures contain large fields 
?ull-path na^es) which are defined statically but contaxn 
variable len^h data, and these data fields wxll typically fill 
OTly a small portion of the allotted space. These large fields 
I^ealwa^f declared as the last member in the P«^ft«,f "^^f?' 
5nly the portion of the message parameter Y^^^^*, 
used must be transmitted across the network. .'l^" 
GRFS to be more efficient because most non object -data GRFS 
messages can be transmitted as a single HRL transport packet. 

CRITICAL ERROR KAHDIiING 

GRFS agent programs must handle critical error situations without 
hanainr the agent's system. When a GRFS agent detects a critical 
e^lr whSl pirf ortning an GRFS co^and. the agent P^^^^^ 
-fail" the operation and set the retcode field appropriately 
(FS DEVICE ERROR, etc) . The agent can also retry the f^^^ 
operation before returning a GRFS status message to the 
application. When a fatal FS error code i^.^turned to the back^ 
application, the application user will be given the opportunity to 
decide whether to retry the failed operation. 
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GRFS Messages Type Values 



GRFS ATTACH_DLE 
GRFS^FIND^FIRST^DLE' 
GRFS FIND_NKXT_DLB 

grfs]Idetach_dle 

GRFS FIND_FIRST_0BJ 

grfs"find next_obj 
grfs^findZclose 

GRFS^CKEATE^OBJ 

GRFS_OPEN_OBJ 

GRFS_RKAD_OBJ 

GRFS_WRITE_OBJ 

GRFS_SEKK_OBJ 

GRFS_VBRIFY_OBJ 

GRFS_CLOSE_OBJ 

GRFS DKLETE_OBJ 

GRFS^GBT_OBJ_INFO 

grfs3^verify_0bj_inf0 
grfs_change_dir 
grfs_gst_c:dr_ddb 
grfs_set"'obj_info 

GRFS ENUM SPECIAL_FIRST 
GRFS^ENUM^SPECIAL^NErr 
GRFS"S PECIAL^EXCLUDE 

grfs""prepare'"dblk 



CTFS RESPONSE! 



GRFS_ATTACH_DLE_STAT 
GRFS_FIND_DLE_STAT 
GRFS_DSTACH_DLE_STAT 
GRFS_FIND OBJ_STAT 

grfs find^close^stat 
grfs3create_obj3stat 
grfs open_obj_stat 

GRFS^READ OBJ_STAT 

GRFS WRITE_OBJ_STAT 

GRFS2SEEK_0BJ_STAT 

GRFS VERIFy_OBJ_STAT 

GRFS"CIOSE_0BJ_STAT 

GRFS_DELETE_OBJ_STAT 

GRFS_GET_OBJ_INFO_STAT 

GRFS VERIFY_OBJ_INFO_STAT 

GRFS'"CHANGE_DIR_STAT 

GRFSJ3ET CDR DDB_STAT 

grfs_set~obj3info_stat 

GRFS ENUM_SPECIAL_STAT 
GRFS"SPECIAL_EXCLUDE_STAT 
GRFS^PREPARS^DBUC STAT 



0x01 

0x02 

0x03 

0x04 

0x05 

0x06 

0x07 

0x08 

0x09 

OxOA 

OxOB 

OxOC 

OxOD 

OxOE 

OxOF 

0x10 

0X11 

0x12 

0x13 

0x14 

0x15 

0x16 

0x17 

0x18 



0x4X 

0x42 

0x44 

0x45 

0x47 

0x48 

0x49 

Ox4A 

Ox4B 

0x4C 

0x4D 

0X4E 

0X4F 

0x50 

0x51 

0x52 

0x53 

0x54 

0x55 

0x57 

0x58 
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CTFS COMMAND MESSAGES MESSAGE P All^AMETER STRUCTURE 



GRFS_ATTACH_DLE 



GRFS_FIND_FIRST_DLE 
GRFS_F1ND_NBXT_DLB 
GRFS_DETACH_DLB 
GRFS_FIND_FIRST_OBJ 



GRFS_FIND_NEXT_OBJ 

GRFS_FIND_CLOSE 

GRFS_CREATE_OBJ 

GRFS_DELETE_OBJ 

GRFS_GKT_OBJ_INFO 

GRFS_VERIFY_OBJ_INFO 

GRFS_SET_OBJ_INFO 

GRFS OPEN OBJ 



Struct GRFS_ATTACH_DLE_PARMS 
CHAR dle_naine IGRFS_MAX_DLE_NAME_LEN] ; 



INBT16 
1NET1€ 
UNET16 



bec_flags 
Bpecial^word; 
max_obj_bsi2e ; 



DLE^HANDLE dle^parent ; 
UINTE8 cmpr_type ; 

CHAR user^name [48] ; 

CHAR paBSword lMAX_PASSOWRD_LEN] ; 



DLE HAND 



DLE HAND 



DLE HAND 



dle_id; 
dle_id; 
die id; 



Struct GRFS_FIKD_FIRST_OBJ_PARMS 

DLE_HAND die . id; 
UNBTl 6 f ind_type ; 

CHAR ename IGRFS_MAX_SNAMBl ; 

In- 



struct GRFS OBJECT FARMS 

DLE_HAND 
GRFS GEN_DBUC 



die id; 
dbllc; 



struct GRFS_OPEN_OBJ_PARMS 



{ 

DLE_HAND 

INET16 

UNITS 

GRFS GEN DBIiK 



dle_id; 
mode; 

reserved [2] ; 
dblK; 



GRFS READ OBJ 



GRFS WRITE OBJ 



struct GRFS_READ_OBJ_PARMS 

OBJ HAND obj_id; 
UNKTX6 size; 
OTBT32 offset; 

}; 

struct GRFS WRITE OBJ^PARMS 
{ " 
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GRFS_SEEK_OBJ 



GRFS_VERIFy_OBJ 



GRFS_CLOSE_OBJ 
GRFS^CHANGE J) IR 



GRFS ENOM SPECIAL^FIRST 

grfsI1enomIspeciai-_next 



GRFS_SPECIAIi_BXClOTE 



OBJ HAND obj_ici; 
UNET32 offset; 
STREAM INFO strm^info; 
UNETIG"" size; 
UINT8 buffer IGRFS^MIN OBJ^SIZEJ ; 

In- 
struct grfs_seek_obj_parms 

OB J_HAND Ob j_id ; 

UNBT32 offset: 

}; 

struct GRFS VERIFY^OBJ^PARMS 
{ 

0BJ_HAND obj_id; 
UNET32 offset; 
STREAM_INP0 Btrm_info; 
UNET16 size; 
UINT8 buffer [GRFS MIN OBJ^SIZBJ ; 

); 

OBJ_HAND obj_id 

Struct GRFS_CHANGE_DIR_PARMS 

DLE HAND dle_id; 
INBT16 size; 
CHAR net path {GRFS MAX_PATH_IiEN) ; 

In- 
struct GRFS_ENUM_SPEC_PARMS 



{ 

DLE^KAND 
UNET16 

1; 



dle_id; 
enuxn^type ; 



struct GRFS_SPEC_EXCLOTB_PARMS 

INETie path^len; 
IRET16 fname^len; 
UINT8 buffer IGRFS MIN_OBJ_SIZB] ; 

}; 
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RRFS RESPONSE MESSAGES 
GRFS_ATTACH_DLE_STAT 



GRFS_FIND_DLB_STAT 



_ MESSAGE PARAMETER STRUCTORE 

Struct GRFS_ATTACH_DIiE_STAT_PARMS 
{ 

DLE_HAND dle_id; 
INETl 6 max_conne c t B ; 

INET16 max_opens_pe reconnect; 

DNET16 procesB^ddbs ; 

INET16 max_obj_bsi2e; 
BOOLEAN Bupports^children; 
tJNETlG path_len 
UINT8 catpr\ypB; 
CHAR current path [GRFS_MAX_PATH_LBH) ; 

7; 

struct GRFS_FIND_DLB_STAT_PARMS 

CHAR die name [GRFS_MAXJDLE_NAME_LKNl ; 
" CHAR " path__delim; 
UINT8 resl ; 

BOOLEAN passwd^req; 
BOOLEAN user_req; 
BOOLEAN dle_writeable; 
BOOLEAN last access_8\jpported; 



INT8 
INT8 
INETX6 
U1NT8 
UINT8 
BOOLEAN 

}; 



os_id; 

f s~type ; 
crypt_type ; 
cmpr_type; 
more^f lag 



GRFS_DETACHJDI-E_STAT 
GRFS FIND OBJ STAT 



none 

struct GRFS FIND_OBJ STAT_PAPMS 

BOOLEAN more^flag; 

UINT8 reserv©d[2] ; 

GRFS GEN DBLK dblk; 
1; " " 



GRFS_FIND_CLOSE_STAT 
GRFS_CREATE_OBJ_STAT 
GRFS JOPEN_OB J ^TAT 



GRFS_READ_OBJ_STAT 



none 



none 



struct GRFS_0PEN_OBJ.STAT_PARMS 



{ 

OBJ HAND 
GRFS GEN_DBLK 

}; " 



obj -id; 
dblk; 



struct GRFS READ OBJ STAT^PARMS 
{ " " " 
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GRFS_WRITE_OBJ_STAT 



GRFS_SEEK_OBJ_STAT 
GRFS_VERIFy__OBJ_STAT 



DNKT16 size; 
DNKT16 blk_size; 
STRKAM_INFO Btr5_info; 
UINT8 buffer IGRFS MIN_OBJ SIZE] ; 

); - 

struct GRFS WRITE OBJ STAT PARMS 
{ " ^ " 

tniETie 

X7NET16 

}; 

UNET32 offset 



blk^Bize; 



struct GRFS_VBRIFy_OBJ_STAT_PARMS 



{ 

UNET16 
HNETIC 

}; 



sxze; 
blk^size; 



GRFS_CLOSE_OBJ_STAT 

GRFS_pEIJKTE_OBJ_STAT 

GRFS_GBTjOBJ_INFO_STAT 

GRFS_VERIFY_OBJ_INFO_STAT 

GRFS_CHANGE_DIR_STAT 

GRFSjGET_CDR_DDB_STAT 

GRPS^SET_OBJ_INFO_STAT 

GRFS_KNOM_SPECIAL_STAT 



none 



none 



GRFS GEN DBLK 



none 



none 



GRFS GEN DBLK 



none 



dblk; 



dblk; 



Struct GRFS BNUM SPECIAL STAT_PARMS 

BOOLEAN more « flag ; 

INET16 path_len; 
INET1€ fname^len? 
UINTd buffer [GRFS UIN OBJ SIZE) ; 
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FS OBJECT_NOT_OPENED obj_id parameter was invalid 
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GRFS RETURN CODES 

The following values have been defined for GRFS agents to use as 
return codes in the retcode field of GRFS response messages: 



SUCCESS 

0UT_OF_MEMORr 
FS_NBVE REATTACHED 

FS_BAD_DBUC 
FS_DLE_NOT_ATTACHED 

F S_STACK_EMPTy 

FS_ACCESS_DENIED 

FS_OUT_OF_S PACE 

FS_NO_MORB 

FS_NOT_FOaND 

FS_INVALID_DIR 

fs_at_root" 

FS objbct_kot_opbned 

fs"eof_reached 

fs""devicb_error 

fs^gdata^different 

fs_security__different 

FS_OPENED_INOSE 
FS_IN_USE_ERROR 

FS info_different 
fs^buffer^to^small 

FS_DE FAULT_S PECI FIED 

FS_RESDATA_DIFFERENT 

FS_INCOMPATIBLE_OBJECT 

FS_K0T_INITIA1iIZBD 

FS_UNDEFINSD_TyPE 

FS NOT^OPBN 

FS"lHVALID DLE 

FS NO^MORE^^DLB 

FS^BAD^DLE^HAtJD 

FS DRIVE_LIST_ERR0R 

FSlArrACH_TO_PARENT 

FS DEVICE_NOT_FOUND 

FS^^BAD^INPUT^DATA 

FS^OS^ATTRXB^DIFFER 

INVALID PATH_DESCRIPTOR 

INVALID^FILE^DESCRIPTOR 

DRrVE_DBSCRIPTOR_ERROR 

FS NO MDRE_CONNECTIONS 

FS""SERVER_ADDR_N0T_FOUND 

fs3mmc_server_connectxons 
fs_bad_attach_to_server 

FS BAD_SERVER_IiOGIN 
FS^SERVER_IOGOOT_DBNIED 

fs3bad_attr_read"" 
fs_eadata_different 

FS^OBJECT^COR RUP T 

FS_ACLDATA_DIFFERENT 

FS CHILDREN NOT^COMPLETE 

FS'*COMM_FAILURB 

FS^NET^DEV^ERROR 

FS 'DONT KANT STREAM 



0x0000 

OxFFFF 

OxFEOl 

6xFE02 

OxFE03 

0XFE04 

OxFEOS 

OxFE06 

0XFE07 

OxFBOS 

OxFB09 

OxFEOA 

OxFBOB 

OxFEOC 

OxFEOD 

OxFEOE 

OxFEOF 

OxFElO 

OxFEXl 

0xFE12 

CxFBia 

0XFE14 

OxFElS 

0XFE16 

0xFB17 

OxFElS 

0XFE19 

OxFElA 

OxFElB 

OxFElC 

OxFElD 

OxFBlE 

OxFElF 

OxF£20 

0xFE2X 

0XFE22 

0XFB23 

0XFB24 

0XFE25 

0XFE26 

OxFE27 

0xFE28 

0XFE29 

0XFE2A 

CxFB2B 

0XFE2C 

OxFE2D 

0XFB2E 

0xFE2F 

0xFE30 

0xFE31 

OxFEBl 
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The following Eection provides a list of likely return code values 
for each of the GRFS response messages. GRFS agents should use 
the return value listed above which provides the best indication 
for the cause of an error. 



GRFS ATrACH_DI*E_STAT 

" FS^ACCESSJDENIED 

FS_INVALID_DIiE 
OUT_OF_MEMORy 

GRFS_FIND_DI.E STAT 

FS IHVAlIlD_DI*E 

fs^no^morb"" 

GRFS DETACH_DI*E__STAT 
" FS_INVALlD_piiE 

GRFS_FIND_OBJ_STAT 

FS INVALID_DIiE 

fs"no more" 



The user or password field was not 
valid. 

The die name was invalid 



dle_id was invalid 

No more DLEs to enumerate 



die id was invalid 



dle_id was invalid 

No more file system objects to 
enumerate 



GRFS FIND_CLOSE STAT 
"* FS_INVALID_DLB 

GRFS_CREATB OBJ STAT 
FS_INVAIiID_DLB 
FS DEVICE ERROR 



FS_ACCESS_DENIED 
FS BAD DBLK 



die id was invalid 



dle_id was invalid 
"hard" device error, unable to 
create 

object 

Agent does not have permission to 

create object 

The DBIiK data is invalid 



GRFS_OPEN_OBJ__STAT 

FS OPENED INaSE 



FS XN USE ERROR 



FS_INVALID_DLB 

FS_NOT_FOUND 

FSJDEVXCE_ERROR 

FS_BAD_DBLK 

FS ACX:ESS DENIED 



Object already oP^nc^ by another 
process, but not locked, and 
BBC_CONFIG flag 
BEC_BACKOP_F1LES_IN_0SE is set 
Object already opened by auiother 
process and locked, 
BEC_BACKIJP_FILES_IN_OSE not set 
dle^id was invalid 
Object not foxind 

"hard" device error, .unsible to open 
object 

The DBUC data was invalid^ 

Agent does not have permission to 

open object 



ODT OF 



GRFS READ OBJ STAT 

FS_DBVTCE_ERROR 
FS_OBJECT_N0T_OPENBD 
FS_EOF_REACHED 
FS ACCESS DENIED 



GRFS_WRITE_OBJ_STAT 

FS_OBJECT_N0T_OPENED 
FS DEVICE ERROR 



"hard" device error read 
obj_id parameter was invalid 
End of File already reached 
Agent does not have permission to 
read object 



obj_id parameter not invalid 
"hard" device write error 
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FS_ODT_OF_SPACE 
FS_ACCESS_DENIED 

FS DONT WWIT STREAM 



Device is full ^ 

Agent does not have permission to 
write object 

Agent does not want to restore this 
data stream 



GRFS_SKEK__OBJ_STAT 

FS_OBJECT_NOT_OPENED 

FS_EOF_REACHED 

FS_DEVICE_ERROR 

GRFS VERIFY OBJ_STAT 

^ FS_OBJECT_NOT_OPENED 
FS DEVICE ERROR 
FS^EOF^REACHED 

fs"gdata_di FFERENT 

FS_SECaRITy_DI FFERENT 

fs_eadata_different 

FS DOOT WANT STREAM 



grfs_close 0BJ_STAT 

fs_object_kot_opened 
fs device error 



obj_id parameter was invalid 
End of File already reached 
"hard" device seek error 



obj_id parameter 'was invalid 
"hard" error 

End of File already .reached 
Object's normal data ' stream does 
not match 

Object's security data stream does 
not match 

Object's extended attribute data 
stream does not match 
Agent does not support this data 
stream type 



obj_id parameter was invalid 
"hard" error 



GRFS DELETE_0BJ_STAT 

FS_INVAI.ID_DUS 

FS_NOT_FOUND 

FS_DEVICE_ERROR 

FS_BAD_DBLK 

FS ACCESS DENIED 



GRFS_GET OBJ_INFO_STAT 
FS^XNVALID^DLE 
FS_NO_MORE 
FS_DEVICE_KRROR 

FS BAD DBLK 



unable to 



dle_id was invalid 
Object not found 
"hard" device error, 
delete object 
The DBLK data was invalid 
Agent does not have permission to 
delete object 



dle_id was invalid 

Object not foiind 

"hard** device error, unable 

delete object 

The DBLK data was invalid 



to 



GRFS_VBRIFY_OBJ_INFO_STAT 
FS_INVALID DLE 
FS NOT_FOUND 
FS^DBVICE^ERROR 

FS BAD DBLK 
FS^INFO DIFFERENT 



dle_id was invalid 
Object not found 

"hard" device error, unable to scan 
device 

The DBLK data was invalid 

The object's attributes do not 

match 



GRFS CHANGE_DIR_STAT 
" FS_INVALID_DLB 
FS_INVAL1D_DIR 

FS DEVICE ERROR 



dle_id was invalid 

netjath D too long, or new path 

does not exist 

"hard" device error, unable to scan 
device 
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GRFS GBT COR DDB^STAT 
FS"lNVAIiID_DLE 
FS DEVICE ERROR 



GRFS SET_OBJ_INFO_STAT 
" FS INVALID DLK 



die id was invalid 

"hard" device error, unable to 

device 



die id was invalid 
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DBLK Fields 

The individual fields within the GRFS common DBLK structure 
which must be manipulated by GRFS agent programs are described 
below. 

blk_type: Defines whether the object is a file or a 

directory. 

files a 08 

directories = 09 

os_id; 

oB_yer; 

ctime : 
atine : 
btime : 

time- These four fields are all defined ac type DATE^TIME 

structures. The DATE_TIMB structure has the following 
format: 

struct DATE_TIME { 

UINT16date__valid; /*tRUE or FALSE */ 

UINT16year; /♦year since 1980 ♦/ 

DINTlgmonth; • /♦ 1 to 12 ♦/ 
UINTlGday; 1 to 31 ♦/ 

UINTlChour; /* 0 to 23 */ 
UINTieminute; 0 to 59 */ 

UINTiesecond; /♦ 0 to 59 ♦/ 

UIKTl6day_of_wee)c; /* 1 to 7 Sun to Sat ♦/ 

}? " 

ctime = Object CREATION time 
atime = Object ACCESSED time 
btime = Object ARCHIVED time 
time = Object MODIFIED time 

If the OS of GRFS Agent being developed does not 
support one or more of the specific time staaps, 
then those time stan^ fields should be reset to 
all zeros. 



size 



The size field contains the size of the normal 
data associated with the object. For instance 
the OS/2 Agent does NOT include the size of BAs 
and ACXiS associated with an object. 

gen attr: This field is a bit-mapped flag which describes 

" the file system attributes of the object* Hie 

following flag values can be contained in this 
field: 

FILE^KORMAL 0x0000 
FILE READONLY 0x0001 
FILB""HIDDKN 0x0002 
FILE^SYSTEM 0x0004 
FIUS^DIRECTORY 0x0010 
FILE_ARCHIVBD 0x0020 

OS info corr5>lete This field is a boolean value which must be set 
" " to TRUE when the all the DBUC information for an 

object has been filled in. 
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min^dcib^info 



min_ddb_si2e 



OBjBpe c^ixif o 



This field contains a pointer to the information 
in the DBLK data area which is required to 
perform either a GRFS_GET_OBJ_INFO or 
GRFS_FIND_NEXT_OBJ command. The infoinnation 
pointed to by this field must be contiguous 
within the data area. Typically the DBLK -find 
information and the object name constitute the 
"MIN DDB INFO" . The DBUC find information xs 
described in the find^info DBLK field. 

This field contains the number of bytes of data 
pointed to by the min_ddb_info field. 

This field contains a pointer to the DBLK data 
area which contains any OS specific information 
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OB__8pec_si2e 



dblk_actual_Bize 



tape_attribs 
find info 



that the GRFS agent would like preserved during 
backup and restoration operations. For instance 
the OS/2 agent uses this area to save HPFS "liOng 
Nsunes" when they are present. As another 
exazrple, a Unix GRFS agent could use this field 
to save information about special device 
placeholder files. 

This field contains the ntjmber of bytes of data 
pointed to by the os_Bpec_info field. 

This field contains the size of the entire DBLK. 
This value is the sum of the size of the GRFS 
DBLK common structure and the number of bytes of 
data within the variable length DBLK data area. 
Remember that the total DBLK must at most 1024 
bytes long. 

not used 

« 

This field contains a pointer to the information 
in DBLK data area which can be used by the GRFS 
agent to perform a GRFS_FIND__NEX7_0BJ command. 
Exanples of this field are the DOS GRFS agent 
passing a DTA structure and the OS/2 agent 
passing the DosFindPirstOKDIR value. 

This field contains the number of bytes of data 
pointed to by the find_info field. 

not used 

not used 

not used 

This field contains a pointer to the path string 
contained within the DBLK data area for a 
directory object. The path string should not 
begin with a path delimeter character xuiless it 
is the root directory of a DLE. The path String 
must be null -terminated. Dxxring backup 
operations the osjpath field and the path field 
will be identical. During restore operations, 
the osjpath field will represent the source" 
path and the path field will represent the 
"destination" path. 

b.d.osjath leng This field contains the length of the path 

" pointed to by the os__path field. This va^ue 

should include the null -termination character. 

This field contains the length of the path 
pointed to by the path field. This value should 
include the null -termination character. 



f ind_inf o_b i 2 e 

obj^type 
translate^f lag 
special_f lag 
b.d.os_path 



b.d.path_leng 
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b.d.path 



This field contains a pointer to the path string 
contained within the DBLK data area ^or^ 
directory object. The path Btrxng should not 
begin with a path delimeter character unless xt 
is the root directory of a DLE. The path Btrxng 
must be null -terminated. During backup 

operations, the path field will be the same as 
the OS path field; however during restore 
operatiSns the path field may be different than 
the osjpath field. 

b.d.inuse attrib This field contains a flag which is " f^^^ 

- files which have been opened but the £iie xs 

currently also opened by another process. 



b.f .os^name 



b.f .name 



This field contains a pointer to the file name 
string contained within the DBLK data area for 
a file object. The path string must be null - 
terminated. The os.name field aiid the name 
field will be the same during backup operations. 
During restore operations the os name fif" 
represents the -source" file name whereas the 
name field represents the "destination" fxle 
name. 

This field contains a pointer to the file name 
string contained within the DBLK data area for 
a file object. The path string must be null- 
terminated. 

Whenever a GRFS agent returns a DLB' s lo?ical root W 
object DBLK, the DBLK data area path etring should be set to 
'\0' and the b.d.o6_path_leng field should be 1. 
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CLAIMS 

What is claimed is: 

1 1. A computer network, comprising: 

2 a) a plurality of computers running disparate 

3 operating systems, respectively; 

4 b) a storage device for backing up and 

5 restoring data processed on the network; and 

6 c) means for performing backup to and restore 

7 from the storage device, including: 

8 i) a GRFS file system running on one of 

9 the said computers; 

10 ii) a plurality of GRFS agents each 

11 running on a respective one of said computers; and 

12 iii) wherein said GRFS file system and 

13 each of said GRFS agents interface with one another via 

14 command and response messages, respectively, said command 

15 and response messages being structured to support the 

16 disparate operating systems. 

1 2. A computer network, according to claim 1, 

2 wherein said disparate operating systems have different 

3 data structure alignments, and said command and response 

4 messages are structured with a least common denominator 

5 alignment for said disparate operating systems • 

1 3. A con^juter network, according to claim 1, 

2 wherein said command and response messages are further 

3 structured to interchange data between said disparate 

4 operating systems. 
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1 4. A computer network, according to claim 3, 

2 wherein said interchange structure of said command and 

3 response messages enable data from one of said computers 

4 running one of said operating systems to backed up to 

5 said storage device and said backed up data to be 

6 restored to another of said computers running another of 

7 said disparate operating systems. 

1 5. A computer network, according to claim 3, 

2 wherein said interchange structure of said messages 

3 includes a streamer header having an identification value 

4 determining whether an associated data stream type is 

5 supported by a given one of said disparate operating 

« 

6 systems. 

1 6. A conputer network, according to claim 1, 

2 wherein said command and response messages are further 

3 structured to enable independent multiple users of said 

4 plurality of computers to request simultaneously backup 

5 or restore of the data. 

1 7. A con?)uter network, according to claim 6, 

2 wherein said command and response messages are structured 

3 with a request id and wherein said GRFS file system may 

4 create a unique request id for every GRFS command 

5 message, whereby the GRFS file system can communicate 

6 simultaneously with multiple GRFS agents. 

1 8. A computer network, according to claim 1, 

2 wherein said plurality of con5>uters each has a user 

3 interface to enable a user to select backup or restore of 

4 selected data. 
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1 9. A computer network, according to claim 1, 

2 wherein said network may have an additional computer not 

3 running a GRFS agent. 



58 



PCTAJS94/12915 

WO 95/13580 




wo 95/13580 PCT/US94/12915 




2/4 

SUBSTITUTE SHEET (RULE 26) 



wo 95/13580 



PCT/US94/12915 



EXAMPLE 1: To bockup a single 5000 byte file. 

Job Monoqer Coinfnond Messoges 



MESSAGE FLOW DIAGRAM FOR BACKUP 



ATTACH DLE{ dle^naite = ^'DougCorapoq" 

dle4)arent = NULL 
inax.obj_bsize = 3276B . 
password = "OpenSesonie") 


GRFS Agent Workstation Response Messages 




AnACH_DLE.STAT{ die. id = 01 

children = TRUE 
iia)Lobj_bsize = 2048) 





FIND.FIRST.DLE( die. id = 01) 



ATTACHJ)LE( 



dle.none = DriveC" 
dle_parcnt = 01 
iiiox.obj.bsize - 32768 
password = 'TO!") 



FIND_riRSTJ)LE.STAT( dle.nanc = 'DriveC" 

passwd_req = TRUE) 



AnACH.DLE.STAT( dle.id = 04 

children = FALSE 
iiiax_ob]_bsize = 2048) 



FIND_FIRST_OBJ( dle.id = 04 




FIND.OBJ.STAT( more.fiog = TRUE 


snane ="*.»") 




dblk (nQne=COMMAND.COM)) 



OPEN OBJ( dle.id = 04 

node = READ.ONLY 

dblk (none=COMMAND.COM)) 



OPEN_OBJ.STAT( ob]_id = 42 

dblk (nane=COlWAND.COM)) 



READ.OBJ( obj id = 42 

size = 2048 ) 



READ.OBJ.STAT( size = 2048 

strnjeoder = NORMALDATA 

buffer[] ) 





READ.OBJ.STAT( size = 2048 

strB.header = MAUD 


READ.OBJ{ objJd = 42 

size = 2048) 






• buffer[]) 



READ.OBJ( objJd = 42 

size = 904 ) 



CLOSLOBJ( objJd = 42) 



READ.OBJ.STAT( size = 904 

slni.header = INVAiiD 

buffer[] ) 



FIM).CLOSE( dle.id = 04 




dblk ) 


1 



CLOSE.OBJ.STAT { ) 



DETACH.DLE{ dle.id = 04 ) 



FIND_CLOSE.STAT( ) 



DETACHJ)LE.STAT{ ) 



OETACH_OLE( dle.id = 01 ) 



DETACHJLE.STAT( ) 
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EXAMPLE 2: To restore a single 5000 byte file. MESSAGE FLOW DIAGRAM FOR RESTORE 

Job Monoqer Coniniond Messoqes GRFS Agent Workstotion Response Messoqes 



ATTACH_DLE( dle.nome = "DougCoiipaq" 
dlcporent = NULL 
iiox_obj_bsi2e = 32768 
password = "OpenSesanie") 



ATTACH.DLE.STAT( die id = 01 

children = TRUE 
BiQx.ob].bsize = 204B) 



FM).FIRST.DLE{ die.id = 01) 



AHACHJLEl dicnoite = "DriveC" 

dle_pQrent = 01 
max.obj.bsize = 32768 

password .= TO!") 



FINDJIRSTJ)LE_STAT( dle_noine = "DriveC" 

posswd.req = TRUE) 



PREPAREJ)BLK( dblk{noiiie=CONFIG.SYS)) 



a™cH.DLE_STAT{ diejd = 04 

children = FALSE 
iiiGx.obj_bsize = 2048) 



GET.0BJECT.INF0( dblk(naine=CQNFIGiYS)) ^ 



CREATL0BJ( dblk(noi!ie=CONFIGSYS)) 



OPEN.OBJ( die.id = 04 

node = WRnE_ONLY 

dblk (norae=CONFIG.SYS)) 



PREPARE_DBLK_STAT( dblk (nor.e=CONFIGiYS)) 



GET.OBJECT.INFO.STAT ( db Ik (noiiie=C0NFIG .SYS)) 



WRITE.OBJ( objJd = 42 
size = 2048 

strnjeoder = NORMALJ)ATA 
buffer[l ) 



CREATE_OBJ_STAT ( ) 



OPEN_OBJ_STAT{ cbj.id = 42 

dblk (nonie=CONFI6.SYS)) 



WRnLOBJ.STAT( size = 2048 ) 



WRnE.OBJ( objJd = 42 

size = 2048 
stri,heoder = INVALID 
buffer[l ) 



WRnLOBJ.STAT( size = 2048 ) 



WRnLOBJ( 



obj_id = 42 
size = 904 

stm.heoder = INVALID 

buffer[] ) 



WRITE 



CLOSE.OBJ( objJd = 42 



CL0SL0BJ.STAT{ ) 



SET.0BJECT.INF0( dblk(naise=C0NFIG5YS)) 



SET.OBJECT.INFO.STAT{ ) 



DETACH_DLE( die.id = 04 



DETACH_OLE.STAT( ) 



DETACH J)LE( die.id = 01 



DETACH.DLE.STAT{ ) 



FIG. 5 
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